Typically, hierarchies that help to structure assignments between objects are administrated through graphical user interfaces, such as the Microsoft Windows Explorer or the cost assignment view of ABC Technologies OROS program.
For example, in the Microsoft Windows Explorer, a folder structure is built in the form of a hierarchy. Objects of three different object types (folders, files and shortcuts) can be graphically assigned to a folder. The computer user, in the following called user, maintains the hierarchy through
a) a combination of menu entries in the drop down menus of the windows explorer,
b) menu entries in a context menu launched with the right mouse button and
c) “drag & drop” functions launched with the left or right mouse buttons. Also shortcuts via the keyboard can be used. For example, new folders or shortcuts can be created by selecting an appropriate menu entry from the “File” menu or from the context menu; for instance, folders or files can be moved or copied by using the right mouse button for “drag & drop”. Files, folders or shortcuts can be deleted by using the context menu with the right mouse button. For each object type only specific activities are allowed. For instance, a folder cannot be graphically assigned to a file or shortcut. A shortcut cannot be graphically assigned to a file but is assigned to the file in a logical relationship.
The OROS program allows the user to graphically define assignments between objects of two different hierarchies. Both hierarchies work similar to the Windows Explorer logic for adding, moving or deleting objects. Both hierarchies support three different object types: center type, account type and cost element type.
For example, a first hierarchy shows the resource view of an enterprise. A center can define a group of resources. Centers can be assigned to other centers. An account can define a specific resource, such as a machine or a building. Accounts can be assigned to centers. A cost element defines a specific type of cost, such as salary, rent etc. Cost elements can be assigned to accounts.
A second hierarchy, for example, shows the activity view of an enterprise, where centers define groups of activities, accounts define activities and cost elements, again, define specific types of cost. Similar to the first hierarchy, cost elements are assigned to accounts and accounts are assigned to centers.
When the user creates an assignment between objects of the first hierarchy and the second one, only accounts of the first hierarchy can be assigned to accounts of the second hierarchy and vice versa. The graphical user interface supports this assignment, for example, by displaying the first hierarchy (sender objects) within a first frame and only the accounts of the second hierarchy (receiver objects) as a flat object list within a second frame. When the user selects an account of the first hierarchy in the first frame, accounts in the second frame become a possible target for the assignment. This is indicated by little arrows icons next to each of the accounts in the second frame. To create the assignment the user selects one account in the second frame by clicking on the corresponding arrow icon and finally enters an assignment category and an assignment value to specify the assignment.
These examples work very well with applications that only use a limited number of object types (three in the examples above) with a limited number of possible relationships between these objects. Therefore, they provide an easy-to-use solution for graphical maintenance of hierarchical assignments in application systems that do not show a high degree of complexity as far as the number of object types and their possible dependencies are concerned. However, more complex application systems, such as Enterprise Resource Planning (ERP) systems (e.g. SAP R/3) usually support a much higher number of object types. Also the number of possible relations between the various object types is very high.
When applying the prior art user interface models to complex application systems, such as ERP systems, the user encounters some inconveniences when creating assignments within or across hierarchies. This becomes obvious, when looking at a typical organizational structure of an enterprise in an ERP system from a cost management point of view. For example, in the SAP R/3 system, a controlling area defines an area that is relevant for an enterprise from a cost management point of view. In each controlling area a hierarchy of cost center groups is defined. Multiple cost centers are assigned to a cost center group. For each cost center multiple cost elements are assigned either directly to the cost center or to activities of the cost center. Cost elements can be grouped into cost element groups. In a further hierarchy internal orders can be defined. Cost centers with cost element groups or activities can be assigned to internal orders. On the other hand internal orders can be assigned back to cost centers. The same is true for projects and project elements. Cost center activities can also be assigned to production or sales orders. For convenience of explanation, further object types and object type relations are not listed here. Numerous further object types and their possible relations to other object types within the same or across hierarchies can be taken from “CO-I Overhead Cost Controlling”, published in September 1999 by SAP AG.
The user desires a clear visualization of all actual and possible dependencies between object types. For assignments across hierarchies a flat list of receiver objects, as in the prior art example, would contain a large amount of objects of different object types. This leaves the task to identify the right receiver object for an assignment completely with the user (e.g., by applying the right mouse button to every single object). To identify the receiver object is difficult because the information about the location of the receiver object within the hierarchy is hidden.